In VoLTE/3GPP (Voice Over LTE/3rd Generation Partnership Project) deployments, when a subscriber roams into a different operator's network (visited network), the signaling is still anchored in the home-network, as the services are provided by the home-network. Given that signaling and media follow the same path, the media also traverses the home network. This doesn't mimic the standard Circuit Switch (CS) call model.
3GPP has defined RAVEL (Roaming Architecture for Voice-over-LTE using Local Break-out) and Optimal Media Routing (OMR) procedures in which the signaling and media take different paths. At a high-level, the OMR procedures involve the following.                Each of the media-processing entities passing Session Description Protocol (SDP)/media attributes that they have received on the ingress side (along with the “realm” information) and passing them to the egress call-leg. This information is passed in newly defined OMR attributes along with the main SDP.        The succeeding nodes make use of main SDP and OMR attributes and decide to include themselves in the media path or not. The “realm” information that is passed in OMR attributes along with other policy information is made use of in arriving at this decision (of media anchoring or not).        
When a roaming UE originates a call, the visited network routes the call towards the home-network. The P-CSCF in the visited-network indicates that this call is eligible for loop-back (using TRF indication in Feature-Caps header) (See Internet Engineering Task Force (IETF) Request for Proposal (RFP) 6809 entitled Mechanism To Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)). This call traverses a set of IBCFs (InterConnect Border Control Functions) which apply OMR procedures at the time of SDP offer itself, based on the indication that the call is eligible for loop-back. (Typically at this point of time, the media is anchored at most/all of the SBCs as the “realm” for various operators would be different).
When the home-network decides to loopback the call towards the visited network, the S-CSCF (Serving-Call Session Control Function) in the home-network would insert an indication that the call is a looped-back call (in Feature-Caps header). When the call is looped back towards the visited network, the call traverses through a set of IBCFs. Each of the IBCFs apply OMR procedures and take themselves out of the path. IBCF applies OMR procedures based on the indication that the call is a looped-back call. The reason why IBCFs would be able to bypass previous node(s) and/or take themselves out of the path is, as the call traverses/loops-back through the same set of “realms” (as it has originally started from). As the IBCFs take bypass previous nodes, the SDP answer is generated with appropriate indication (c=0.0.0.0 is defined with specific semantics) so that intermediaries know that they have been bypassed.
Furthermore, with the advent and proliferation of different technologies, each of which is optimized for different access-types and each of which employ different codecs, it is not an uncommon phenomenon that the call gets transcoded as it traverses through networks employing different kinds of technology. For e.g., in LTE network AMR (Adaptive Multi-Rate codec) is used for voice; in CDMA networks EVRC (Enhanced Variable Rate Codec) is used for voice; in a WebRTC network OPUS a lossy audio coding format developed by the IETF is used for voice; in a traditional PSTN (Public Switched Telephone Network) network G711 is used for voice. On a similar note, different codecs are employed for video too. For e.g., in LTE network H.264 is recommended for video; in a WebRTC network VP8 video encoding format is used for the same.
This creates the need for SBC (Session Border Controller) vendors to provide transcoding not only for audio streams but also video streams. The SBC nodes provide video transcoding by invoking MRF nodes, which have specialized functions to provide audio and video transcoding. The SBCs typically invoke MRF (Media Resource Function) nodes using SIP-based interface i.e. the call is routed via an MRF and MRF egresses the call by acting as a SIP B2BUA (Back to Back User Agent).
As a SBC invokes MRF in anticipation of transcoding (pro-active transcoding approach), it may turn out after the offer-answer model, the call doesn't need to be transcoded. Typically MRFs don't support OMR procedures and hence the MRF continues to be in the media path (even when transcoding is not invoked).
One of the main issue with current OMR procedures is that all the intermediaries must support OMR procedures. If intermediaries don't support OMR procedures, the OMR attributes are NOT carried forward and succeeding nodes can't invoke OMR procedures. Even if OMR attributes are passed as un-known attributes, certain validations as defined by the OMR procedures (in 3GPP TS 29.079) fail and OMR procedures are NOT invoked. This is correct since a Non-OMR node can't be instructed to bypass itself (and thus release local media resources) using OMR-specific semantics in an SDP answer. Furthermore, the OMR procedures are difficult to implement. As a result, when even one intermediary node does not support OMR procedures optimal media routing cannot be obtain and intermediary nodes, media resources, and devices resources are wasted. This is a technological communications network centric problem, e.g., Internet problem, in which the lack of optimal media routing results in subpar network performance, unnecessary network congestion, routing of media through intermediary nodes or MRF resources unnecessarily resulting in wasted resources, e.g., MRF resources, an inability to support media streams due to resources being allocated which are not being used, additional expenses in routing and anchoring media at one or more devices in one or more different networks needlessly, and/or the introduction of unnecessary delays, noise and distortion into the media streams which are not optimally routed.
From the above discussion, it should be appreciated that there is a need for improved communications methods, systems and apparatus for achieving optimized media paths in an asynchronous network. Furthermore, there is a need for improved communications methods, systems and apparatus for determining and optimizing media paths which include Non-OMR (Non-Optimal Media Routing) nodes that is nodes which do not implement 3GPP OMR procedures. There is also a need for communications methods, systems and apparatus which determine media routing paths in which intermediary nodes in a media path can be bypassed so as to free up intermediary nodes and MRF resources and in doing so overcome one or more of the aforementioned technological problems resulting from non-optimal routing of media. There is also a need to determine and achieve improved media path routing in media, e.g., video, pass-through scenarios involving external transcoders/media server so that these devices resources can be freed up or made available for other media streams. Moreover, there is a need for improved media path routing wherein a MRF device may initially exclude itself from a media path but be subsequently added to the media path if necessary such as for example a subsequent need for trancoding of the media of the session. Furthermore, there is a need for technological improvements to session border controllers so that they can be operated to achieve optimal media routing for communications session with media streams when one or more nodes/devices on the media routing path for the communications session do not implement 3GPP OMR procedures.